fix(pd): resolve hostname entries in IpAuthHandler allowlist#2962
fix(pd): resolve hostname entries in IpAuthHandler allowlist#2962bitflicker64 wants to merge 1 commit intoapache:masterfrom
Conversation
…at startup to avoid Netty DNS blocking
|
How I tested:
Results with pd2 as leader and hostnames only: Before this fix: After this fix: Hostnames are resolved to IPs at startup via |
There was a problem hiding this comment.
Pull request overview
Fixes PD Raft inbound connection allowlisting when the configured allowlist contains hostnames (e.g., Docker bridge service names) by resolving those hostnames to IPs up front and validating connections via a simple set lookup.
Changes:
- Resolve allowlist entries via
InetAddress.getAllByName()at handler construction time - Cache resolved IPs in an immutable
Setused byisIpAllowed() - Log a warning when an allowlist hostname can’t be resolved
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| return resolved.isEmpty() || resolved.contains(ip); | ||
| } | ||
|
|
||
| private static Set<String> resolveAll(Set<String> entries) { |
There was a problem hiding this comment.
|
|
||
| private IpAuthHandler(Set<String> allowedIps) { | ||
| this.allowedIps = Collections.unmodifiableSet(allowedIps); | ||
| this.resolvedIps = resolveAll(allowedIps); |
There was a problem hiding this comment.
resolvedIps is only built once in the constructor, but IpAuthHandler is still a JVM-wide singleton. RaftEngine#changePeerList() can replace the peer set after startup, and hostname-based peers can also resolve to a different IP later. In both cases this handler keeps the original resolved addresses forever, so a valid PD peer can be blocked until the whole process restarts. Please add a refresh path for membership/DNS changes, or defer hostname resolution to validation time with a bounded cache/TTL.
peer hostname
|
v
startup resolve once
|
v
resolvedIps (singleton, frozen)
|
+--> peer list changed
|
+--> DNS changed
|
v
new peer IP not in set
|
v
connection blocked
Purpose of the PR
IpAuthHandleronly compared the client IP with the allowlist entries directly.When the allowlist contains hostnames, connections from their resolved IPs could be rejected.
Main Changes
InetAddress.getAllByNameSet.contains()lookupVerifying these changes
Does this PR potentially affect the following parts?
Documentation Status
Doc - TODODoc - DoneDoc - No Need